arXiv:l506.04205v2 [cs.PL] 22 Aug 2015 


In Proceedings of the ACM Dynamic Languages Symposium (DLS) 2015 


Gradual Certified Programming in Coq 


Eric Tanter 


Nicolas Tabareau 


PLEIAD Lab, Computer Science Dept (DCC) 
University of Chile, Santiago, Chile 
etanter@dcc.uchile.cl 


Inria 

Nantes, France 
nicolas.tabareau@inria.fr 


Abstract 

Expressive static typing disciplines are a powerful way to 
achieve high-quality software. However, the adoption cost 
of such techniques should not be under-estimated. Just 
like gradual typing allows for a smooth transition from 
dynamically-typed to statically-typed programs, it seems 
desirable to support a gradual path to certified program¬ 
ming. We explore gradual certified programming in Coq, 
providing the possibility to postpone the proofs of selected 
properties, and to check “at runtime” whether the properties 
actually hold. Casts can be integrated with the implicit coer¬ 
cion mechanism of Coq to support implicit cast insertion a 
la gradual typing. Additionally, when extracting Coq func¬ 
tions to mainstream languages, our encoding of casts sup¬ 
ports lifting assumed properties into runtime checks. Much 
to our surprise, it is not necessary to extend Coq in any way 
to support gradual certified programming. A simple mix of 
type classes and axioms makes it possible to bring gradual 
certified programming to Coq in a straightforward manner. 

Categories and Subject Descriptors D.3.3 [Software]: 
Programming Languages—Language Constructs and Fea¬ 
tures; F.3.1 [Logics and Meanings of Programs ]: Spec¬ 
ifying and Verifying and Reasoning about Programs— 
Specification Techniques 

Keywords Certified programming, refinements, subset types, 
gradual typing, casts, program extraction, Coq. 

1. Introduction 

In Certified Programming with Dependent Types , Chlipala 
sketches two main approaches to certified programming @|. 
In the classical program verification approach, one sepa¬ 
rately writes a program, its specification, and the proof that 
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the program meets its specification. A more effective tech¬ 
nique is to exploit rich, dependent types to integrate pro¬ 
gramming, specification and proving into a single phase: 
specifications are expressed as types, as advocated by Sheard 
et al. iQ in what they call language-based verification. 
While rich types are a powerful way to achieve high-quality 
software, we believe that the adoption cost of such tech¬ 
niques is not to be under-estimated. Therefore, it seems de¬ 
sirable to support a gradual path to certified programming 
with rich types, just like gradual typing allows for a smooth 
transition from dynamically-typed to statically-typed pro¬ 
grams G3. Indeed, the idea of progressively strengthen¬ 
ing programs through a form of gradual checking has al¬ 
ready been applied to a variety of type disciplines, like types- 
tates 171301- information flow typing and security types |8. 
1§], ownership types [24], annotated type systems |281, and 
effects 0|. Recent developments like property-based test¬ 
ing for Coq [0] and randomized testing based on refinement 
types annotations |23l are complementary efforts to make 
language-based verification more practical and attractive. 

In this article, we consider a gradual path to certified pro¬ 
gramming in Coq, so that programmers can safely postpone 
providing some proof terms. We focus mostly (but not ex¬ 
clusively) on subset types, which are the canonical way to 
attach a property to a value. Subset types are of the form 
{a:A | Pa), denoting the elements a of type A for which 
property P a holds. More precisely, an inhabitant of {a: A \ 
P a} is a dependent pair (a ; p), where a is a term of type A, 
and p is a proof term of type P a. 

Constructing a value of type {a:A \ P a} requires the 
associated proof term of type P a. Currently, Coq has two 
mechanisms to delay providing such a proof term. First, one 
can use Program, a facility that allows automatic coercions 
to subset types leaving proof obligations to be fulfilled af¬ 
ter the definition is completed [27]. This is only a small de¬ 
lay however, because one must discharge all pending obliga¬ 
tions before being able to use the defined value. The second 
mechanism is to admit the said property, which makes Coq 
accept a definition on blind faith, without any proof. This 
solution is unsatisfactory from a gradual checking point of 
view, because it is unsafe: there is no delayed checking of 
the unproven property. Therefore, a function that expects a 
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value with a given property might end up producing incor¬ 
rect results. The motto of gradual checking, trust but verify, 
is therefore not supported. 

The main contribution of this work is to provide safe 
castsQ for Coq, paving the way for gradual certified pro¬ 
gramming, and to show that this is feasible entirely within 
standard Coq, without extending the underlying theory and 
implementation. When casting a value a of type A to the rich 
type {a\A \ P a), the property P a is checked as needed, 
forbidding unsafe projection of the value of type A from the 
dependent pair. Note that because Coq is dependently-typed 
(ie. types can be dependent arbitrarily on computations and 
values), there is no rigid compile-time/runtime distinction: 
therefore, cast errors can possibly occur both as part of stan¬ 
dard evaluation (triggered with Eval) and as part of type 
checking, during type conversion. 

A key feature of our development is that we support a 
smooth gradual path to certified programming that avoids 
imposing a global monadic discipline to handle the possibil¬ 
ity of cast errors. Technically, this is achieved thanks to the 
(possibly controversial) choice of representing cast failures 
in Coq as an inconsistent axiom, so that failed casts manifest 
as non-canonical normal forms (e.g. a normal form of type 
bool is either true, false, or a cast failure). 

Section [2] provides an informal tour of gradual certified 
programming with subset types in Coq, through a number 
of examples. We then dive into the details of the approach, 
namely type classes for decidability (Section 0 and an ax¬ 
iomatic representation of casts (Section |U). Section [5] then 
discusses implicit cast insertion a la gradual typing. Sec¬ 
tions [6] and [7] focus on higher-order casts, with both sim¬ 
ple and dependent function types—the latter being subtly 
more challenging. Section [8] describes the use of casts to 
protect functions extracted to mainstream languages that do 
not support subset types. Section [9] briefly describes the 
main properties of our approach, which follow directly from 
being entirely developed within standard Coq. Section [TO] 
shows how our approach scales beyond subset types to other 
dependently-typed constructions, such as record types, and 
illustrates how it is possible to customize the inference of 
decision procedures. Section [IT] discusses related work and 
Section[T2lconcludes. 

The code presented in this paper is available as a Coq 
library at https : //github. com/tabareau/Cocasse 

2. Gradual Certified Programming in Action 

We start by introducing gradual certified programming with 
subset types through a number of examples of increasing 
complexity, culminating in a small gradually certified com¬ 
piler. For now, we only appeal to the intuition of the reader; 

1 Note that we use the name “cast” in the standard way Cl to denote a 
type assertion with an associated runtime check—this differs from the non- 
traditional use of “cast” in the Coq reference manual (1.2.10) where it refers 
to a static type assertion. 


we discuss the technical details of the approach in Section [3] 
and beyond. 

2.1 First Examples 

We now show how casts behave with examples. In this pa¬ 
per, we denote the first and second projections of a pair as .1 
and .2 respectively. First consider a simple definition that is 
rejected by Coq: 

Definition n_not_ok : {n:nat | n < 10} := 5. 

This definition is rejected, because the value should be a 
dependent pair, not just a natural number. Using Programf| 
we are left with the obligation to prove that 5 < 10, which is 
arguably not too hard. 

We could instead use our basic cast operator—denoted 
?—to promote 5 to a value of type (n:nat | n < 10}. The 
semantics is that, if we ever need to evaluate n_goodfi we 
will check whether 5 is less than 10: 

Definition n_good : {i: nat | n < 10} := ? 5. 

Eval compute in n_good. 

= (5; Le.le_n_S 5 9 (...)) 

: {n : nat I n < 10} 

We indeed have a dependent pair, whose first component is 
the number 5 and second component is the proof that 5 < 10 
(elided). We can naturally project the number from the pair: 

Eval compute in n_good.i. 

= 5 
: nat 

Of course, we may be mistaken and believe that 15 < 10: 
Definition n_bad : {rr. nat | n < 10} := ? 15. 

The cast error now manifests whenever we evaluate n_bad: 
Eval compute in n_bad. 

= failed_cast 15 (16 <= 10) 

: {n : nat I n < 10} 

Importantly, a failed cast does not manifest as an excep¬ 
tion or error, since Coq is a purely functional programming 
language. Instead, as we will explain further in Section [4] 
f ailed_cast is a normal form (ie., it cannot be further re¬ 
duced) of the appropriate subset type, which indicates both 
the casted value (15) and the violated property (16 < 10). 

Crucially, because n_bad evaluates to a failed cast, we 
cannot project the natural number, since we do not even have 
a proper dependent pair: 

2 Program is a definition facility that allows automatic coercions to subset 
types leaving proof obligations to be fulfilled after the definition is com¬ 
pleted El , but before the definition can be used. 

3 Coq does not impose any fixed reduction strategy. Instead, Eval is param¬ 
eterized by a reduction strategy, called a conversion tactic, such as cbv (aka. 
compute), lazy, hnf, simpl, etc. 
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Eval compute in n_bad-i. 

= let (a, _) := 

failed_cast 15 (16 <= 10) in a 
: nat 

At this point, it is worthwhile illustrating a major differ¬ 
ence with the use of admit, to which we alluded in the intro¬ 
duction. Consider that we use admit to lie about 15: 

Program Definition n_real_bad : {,t: nat | n < 1C) := 
15. 

Next Obligation. Admitted. 

In this case, n_real_bad is an actual dependent pair, with the 
use of proof ^admitted (an inhabitant of False) in the second 
component: 

Eval compute in n_real_bad. 

= (15; match proof_admitted return (16 <= 10) 

. . .) 

: {n : nat I n < 10} 

This means that we are able to project the number from 
n_real_bad without revealing the lie: 

Eval compute in n_real_bad.i. 

= 15 
: nat 

2.2 Casting Lists 

Casting a list of elements of type A to a list of elements of 
type {a: A \ P a} simply means mapping the cast operator 
? over the list. For instance, we can claim that the following 
list is a list of 3s: 

Definition list_of_3: list nat | n = 3} := 
map ? (3 :: 2 :: 1 :: nil). 

If we force the evaluation of list_of_3, we obtain a list of 
elements that are either 3 with the proof that 3 = 3, or a failed 
cast: 

Eval compute in list_of_3. 

= (3; eq_refl) 

:: failed_cast 2 (2=3) 

:: failed_cast 1(1=3) :: nil 
: list {n : nat I n = 3} 

Note the difference between a list of type list {a : A \ 
P a} and a list of type {/ : list A \ P /}. While the former 
expresses that each element a of the list satisfies P a, the 
latter expresses that the list / as a whole satisfies P 1. Casting 
works similarly for other inductively-defined structures. 

2.3 A Gradually Certified Compiler 

We now show how to apply casts to a (slightly) less artificial 
example. Consider a certified compiler of arithmetic expres¬ 
sions, adapted from Chapter 2 of CPDT |@]. 


Source language. The source language includes the fol¬ 
lowing binary operations: 

Inductive binop : Set := Plus | Minus | Times. 

Expressions are either constants or applications of a bi¬ 
nary operation: 

Inductive exp : Set := 

| Const : nat —r exp 
| Binop : binop —r exp — t exp —r exp. 

The semantics of binary operations is as expected: 

Definition evalBinop ( b : binop) : nat —/ nat —t nat := 
match b with 
| Plus =$■ plus 
| Minus => sub 
| Times =>■ mult 
end. 

So is the semantics of evaluating expressions: 

Fixpoint evalExp (e: exp) : nat := 
match e with 
| Const n => n 
| Binop b el e2 =>■ 

(evalBinop b) (evalExp el) (evalExp e2) 

end. 

Stack machine. We now introduce the intermediate lan¬ 
guage of instructions for a stack machine: 

Inductive instr : Set := 

| iConst : nat —/ instr 
| iBinop : binop —t instr. 

A program is a list of instructions, and a stack is a list of 
natural numbers: 

Definition prog := list instr. 

Definition stack := list nat 

Executing an instruction on a given stack produces either 
a new stack or None if the stack is in an invalid state: 

Definition runlnstr (i: instr) (s: stack): option stack := 
match i with 

| iConst n =>• Some (n :: s) 

| iBinop b => 
match s with 

| argl :: arg2 :: s' =>■ 

Some ((evalBinop b) argl arg2 :: s') 

| _ => None 
end 

end. 

Running a program simply executes each instruction, recur¬ 
sively: 

Fixpoint runProg ( p : prog) (s: stack): option stack := 
matchp with 
| nil =t> Some s 

| i:: p’ => match runlnstr i s with 
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| None =>• None 
| Some s’ =k runProg p’ s’ 


Compiler. We now turn to the compiler, which is a recur¬ 
sive function that produces a program given an expression: 

Fixpoint compile (e: exp) : prog := 
match e with 
| Const n => iConst n :: nil 
| Binop b el e2 => 

compile el ++ compile e2 ++ iBinop b :: nil 
end. 

Hint: there is a bug! 

Correct? Of course, one would like to be sure that compile 
is a correct compiler. The traditional way of certifying the 
compiler is to state and prove a correctness theorem. In 
CPDT, the compiler correctness is stated as follows: 

Theorem compile_correct : V ( e : exp), 

runProg (compile e ) nil = Some (evalExp e :: nil). 

Namely, executing the program returned by the compiler on 
an empty stack yields a well-formed stack with one element 
on top, which is the same value as interpreting the source 
program directly. 

It turns out that the theorem cannot be proven directly 
by induction on expressions because of the use of nil in the 
statement of the theorem: the induction hypotheses are not 
useful. Instead, one has to state a generalized version of the 
theorem, whose proof does go by induction, and then prove 
compile .correct as a corollary |5[]. 

Instead of going into such a burden as soon as the com¬ 
piler is defined, one may want to assert correctness and have 
it checked dynamically. With our framework, it is possible to 
simply cast the compiler to a correct compiler. To make the 
following exposition clearer, we first define what a correct 
program (for a given source expression) is: 

Definition correct.prog ( e : exp) (p: prog) : Prop := 
runProg p nil = Some (evalExp e :: nil). 

To exploit gradual certified programming to claim that 
compile is correct using a cast, we could try to use our cast 
operator ?, to attempt to give compile the type {/: exp — > 
prog | V e:exp, correct.prog e (f e)}. This is however unde- 
cidable because the property quantifies over all expressions. 
(In fact, such a cast is rejected by our framework, as dis¬ 
cussed in Section[3]) Instead, we need to resort to a higher- 
order cast operator, denoted V?, which can lazily check that 
the compiler is “apparently” correct by checking that it pro¬ 
duces correct programs whenever it is used: 

Definition correct.comp := 

V e: exp, {p: prog | correct.prog e p } 

Definition compile.ok : correct.comp := V? compile. 


Let us now exercise compile.ok. The following evaluation 
succeeds: 

Eval compute in 

compile.ok (Binop Plus (Const 2) (Const 2)). 

= (iConst 2 :: iConst 2 :: iBinop Plus :: nil; 
eq.ref1) 

: {p : prog I correct.prog ...} 

However, the cast fails when using a (non-commutative!) 
subtraction operation: 

Eval compute in 

compile.ok (Binop Minus (Const 2) (Const 1)). 

= failed.cast (iConst 2 :: iConst 1 

:: iBinop Minus :: nil) 
(Some (0 :: nil) = Some (1 :: nil)) 
: {p : prog I correct.prog ...} 

Indeed, the compiler incorrectly compiles application 
nodes, compiling sub-expressions in the wrong order! The 
last argument of failed.cast—the invalid property—is 
explicit about what went wrong: the compiler produced a 
program that returns 0, while the interpreter returned 1. 

Finally, suppose we write a rune function that requires a 
correct compiler as argument: 

Definition rune ( c : correct.comp) (e: exp) := 
runProg (c e ). i nil 

We can use the cast framework to pass compile as ar¬ 
gument, but in case the compiler behaves badly, nine fails 
because it cannot apply the projection .i to a failed cast: 

Eval compute in rune (V? compile) 

(Binop Minus (Const 2) (Const 1)). 

(let (a, _) := failed.cast 

(Some (0 :: nil) = Some (1 :: nil)) ... 

: option stack 

Again, note that if we had used admit to lie about compile, 
then rune would not have detected the violation of the prop¬ 
erty, and would have therefore returned an incorrect result. 

3. Casts and Decidability 

What exactly does it mean to cast a value a of type A to a 
value of the rich type {a : A \ P a}? There are two challenges 
to be addressed. First, because we are talking about safe 
casts, it must be possible to check, for a given a, whether 
P a holds. This means that P a must be decidable. Second, 
because it may be the case that P a does not hold, we must 
consider how to represent such a “cast error”, considering 
that Coq does not have any built-in exception mechanism. 
For decidability, we exploit the type class mechanism of 
Coq, as explained in this section. For failed casts, we exploit 
axioms (Sectional. 
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3.1 Decidable Properties 

The Decidable type class, which is used in the Coq/HoTT li- 
brarjQ, is a way to characterize properties that are decidable. 
To establish that a property is decidable, one must provide 
an explicit proof that it either holds or not: 

Class Decidable (P : Prop) := dec : P + -> P . 

Note that the disjunction is encoded using a sum type (+, 
which is in Type) instead of a propositional disjunction (V, 
which is in Prop) in order to support projecting the under¬ 
lying proof term and use it computationally as a decision 
procedure for the property^ 

The Coq type class system can automatically infer the 
decision procedure of a complex property, using type class 
resolution, when a cast is performed. For that, the appropri¬ 
ate generic decidability instances must be provided first, but 
those instances are implemented only once and are already 
part of the Decidable library or can be added as needed. For 
example, the following instance definition (definition omit¬ 
ted) allows Coq to infer decidability—and build the asso¬ 
ciated decision procedure — for a conjunction of two decid¬ 
able properties by evaluating the decision procedure for each 
property: 

Instance Decidable_and (P Q: Prop) (HP : Decidable P) 
(HQ : Decidable Q) : Decidable (P A Q). 

Also, whenever a proposition has been proven, it is obvi¬ 
ously decidable (ini is the left injection on a sum type): 

Instance Decidable_proven (P : Prop) (ev : P): 

Decidable P := ini ev. 

This instance allows programmers to mix proven and decid¬ 
able properties, for instance by inferring that P A Q is decid¬ 
able if P is decidable and Q is proven. 

Another interesting instance is the one exploits the fact 
that every property that is equivalent to a decidable property 
is decidable: 

Definition Decidable_equivalent {P P’ : Prop} 

(HPP’ T’ttf) ‘{Decidable P’} : Decidable P. 

We will exploit this instance in Section [10] to synthesize 
more efficient decision procedures. 

If type class resolution cannot find an instance of the 
Decidable class for a given property, then casting to a subset 
type with that property fails statically. This happens if we 
try to cast compile directly to a function subset type with a 
universally-quantified property, as discussed in Section[2] 


4 https://github.com/HoTT/HoTT 

5 An equivalent decision procedure mechanism is implemented in the Ssre- 
flect library IH, using boolean reflection. We discuss the differences be¬ 
tween the two approaches in Appendix [A] It must be noticed already that 
the differences are minor and our cast mechanism works perfectly well with 
both ways of formalizing decidability. 


3.2 Leveraging Type Class Resolution 

Depending on the structure of the property to be established, 
we can get decidability entirely for free. In fact, in the com¬ 
piler example (Section l2T3l i. the decidability of correct_prog 
was automatically inferred! We now explain how this au¬ 
tomation was achieved. 

The correct_prog property is about equality of the results 
of running programs, which are option stacks, or more ex¬ 
plicitly, option list nats. The Decidable type class already 
allows, with its instances, to automatically obtain complex 
correct decision procedures based on composition of atomic 
ones (Sect.[3]). For correct_prog to enjoy this full automation, 
the Decidable library needs to include instances that allow 
equality of lists and options to be inferred. More precisely, 
we provide a type class for decidable equality, Decidable = o 

Class Decidable = (A : Type) := 

{ eq_dec : V a b : A, Decidable (a = b) }. 

Based on this decidable equality class, we can define once 
and for all how to derive the decidability of the equality 
between lists of A or options of A provided that equality is 
decidable for A: 

Instance Decidable_eq_list : VA (HA: Decidable = A) 

(l l’: list A), Decidable (l = l’). 

Instance Decidable_eq_option : VA (HA: Decidable^ A) 
(o o’: option A), Decidable (o = o’). 

By also declaring the corresponding Decidable = in¬ 
stances for the list and option type constructors, the type 
class resolution mechanism of Coq is able to automatically 
build the correct decision procedures for properties that state 
equality between arbitrary nestings of these type construc¬ 
tors, such as correct_prog. A well-furnished decidability li¬ 
brary allows developers to seamlessly enjoy the benefits of 
gradual certified programming. 

We come back to decidability in Section [TOj when de¬ 
scribing casts on rich records, in order to show how one can 
specialize the decision procedure to use in specific cases, for 
instance to obtain a procedure that is more efficient than the 
default one. 

4. Casts and Axioms 

Intuitively, the basic cast operator ? should be defined as a 
function cast of type A — > {a : A \ P a} (assuming that P a 
is decidable). To perform such a cast implies exploiting the 
decidability of P a: checking (and hence evaluating) whether 
P a holds or not. If it holds true, the cast succeeds. The cast 
function can simply return the dependent pair with the value 
a and the proof. If P a does not hold, the cast fails. How 
should such errors manifest? 


6 A similar type class is also used in the Coq/HoTT library under the name 
DecidablePaths. 
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4.1 The Monadic Approach 

The traditional way to support errors in a purely functional 
setting is to adopt a monadic style. For instance, we could 
define cast to return option {a:A \ P a} instead of just 
{a:A | P a). Then, a cast failure would simply manifest 
as None. This is all well and understood, but has serious 
consequences from a software engineering point of view: it 
forces all code that (potentially) uses casts to also be written 
in monadic style. Because the philosophy of gradual typing 
entails that casts may be added (or removed) anywhere as 
the software evolves, it means that the entire development 
has to be defensively written in monadic style. For instance, 
consider the definition of rune in Section [231 

Def initionrunc (c: correct_comp) (e: exp) := 
runProg (c e). 1 nil 

If it were possible to check eagerly that compile is cor¬ 
rect, the monadic cast would produce a value of type option 
correct_comp, and the client calling rune (? compile) would 
simply have to locally deal with the potential of failure. 
However, since correct_comp is undecidable, the only so¬ 
lution is to delay casts, which means that the casted com¬ 
piler would now have type V e : exp, option {p : prog \ 
correct_prog e p}. This in turn implies that all users of the 
compiler (such as rune) have to be prepared to deal with op¬ 
tional values. The argument type of rune would have to be 
changed, and its body as well because (c e) would now return 
an option correct_prog, not a correct_prog. This non-local 
impact of deciding to statically establish guarantees or defer 
them to runtime is contrary to the smooth transition path that 
gradual typing is meant to support. 

After all, every practical functional programming lan¬ 
guage does some compromise with purityj, supporting side 
effects like references and exceptions directly in the lan¬ 
guage, rather than through an explicit monadic encoding. 
The upside of sacrificing purity is that these side effecting 
operations can be used “transparently”, without having to 
adopt a rigid discipline like monads, which—despite various 
improvements such as |22]—is still not free from software 
engineering challenges. So, what does it mean to embed cast 
errors in such a transparent manner in Coq? 

4.2 The Axiomatic Approach 

We introduce a novel use of axioms, not to represent what is 
assumed to be true, but to represent errors. This allows us to 
provide the cast operator as a function of type A — > {a : A \ P 
a}. Specifically, we introduce one axiom, failed_cast, which 
states that for any indexed property on elements of type A, 
we can build a value of type {a : A \ P a}:@ 

7 Even Haskell has impure features such as undefined, unsafeCoerce 
and unsaf ePerf ormlO, for pragmatic reasons. 

8 We declare the two first arguments of failed^cast as implicit (between {}), 
and only leave the value a and the msg argument as explicit. The argument 
msg is apparently redundant, since it is just defined as P a in cast; however, 


Axiom failed_cast : V {A:Type} {P : A —t Prop} 

( a:A ) (msg: Prop), {a : A \ Pa} 

Obviously, failed_cast is a lie. This lie is used in the 
definition of the cast operator, in case the decision procedure 
indicates that the property does not hold: 

Definition cast (A:Type) (P : A —r Prop) 

(i dec : V a, Decidable (P a)) : A — t {a : A \ P c } := 

fun a: A => 

match dec a with 
| ini p => (a ; p) 

| inr _ =>• failed_cast a (P a) 
end. 

The cast operator applies the decision procedure to the 
given value and, depending on the outcome, returns either 
the dependent pair with the obtained proof, or a failed_cast. 
Considering the definition of cast, we see that a cast fails if 
and only if the property P a does not hold according to the 
decision procedure. 

A subtlety in the definition of cast is that the casted value 
must not be exposed as a dependent pair if the decision 
procedure fails. An alternative definition could always return 
(a ; x) where x is some error axiom if the cast failed. Our 
definition has the advantage of reporting a cast failure as 
soon as the casted value is used (even though the property 
attached to it is not)@ 

We introduce the ? notation for cast, asking Coq to infer 
the property and the evidence of its decidability from the 
context: 

Notation ”?” := (cast _ ). 

4.3 Heresy! 

Using an axiom to represent failed casts is (slightly!) hereti¬ 
cal from a theoretical viewpoint. As a matter of fact, one can 
use a cast to inhabit False, for instance by pretending that 0 
comes with a proof of False and then projecting the second 
component: 

Definition unsound : False := (? 0) .2 - 

In this sense, the monadic approach is preferrable, as it 
preserves consistency. However, the axiomatic approach is 
an interesting alternative to using plain axioms and admitted 
definitions in Coq—which are, after all, the only pragmatic 
solutions available to a Coq practitioner who does not want 
to wrestle with a given proof immediately. Axiomatic casts 
are superior in many ways: 

• As discussed above, we cannot project the value compo¬ 
nent of a subset type with a failed cast (recall that using 
admit provides no such guarantee). 

declaring it as an explicit argument together with a allows for clear and 
concise error messages when cast fails, reporting the violated property for 
a given value, as illustrated in Section [2] 

9 Appendix B briefly discusses the interplay of evaluation regimes and the 
representation of cast failures as non-canonical normal forms. 
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• When things go right (i.e. the cast succeeds), there is no 
axiom or admitted definition that will block type conver¬ 
sion and evaluation. 

• Statically establishing a property or using a cast does not 
affect the types involved, so the programmer can seam¬ 
lessly navigate the gradual checking spectrum without 
having to perform non-local refactorings. 

All in all, both the monadic and axiomatic approaches 
to gradual verification are feasible, and are likely to please 
different crowds. In fact, we have implemented both ap¬ 
proaches in the Cocasse library. In this paper we focus on 
the axiomatic approach, because of its disruptive potential 
and software engineering benefits. We believe this approach 
will be more appealing to pragmatic practitioners who are 
willing to compromise consistency to some extent in order 
to enjoy a smooth gradual verification environment. Also, as 
we discuss in Section[l2] there are alternatives to be explored 
to make the axiomatic approach less heretical. 


5. Implicit Casts 


The major technical challenge addressed in this work is 
to provide casts for subset types within Coq. These casts 
have to be explicitly placed by programmers, much like 
in the seminal work of Abadi el al. on integrating static 
and dynamic typing fit], or in the gradual information flow 
type system proposed by Disney and Flanagan @]. Gradual 
typing is however generally associated with a mechanism 
of implicit cast insertion: the source language, which may 
not even feature explicit casts, is translated to an internal 
language with explicit casts 12611 . 

It is possible to achieve implicit cast insertion in Coq by 
exploiting the implicit coercion mechanismF^ 


Implicit coercions in a nutshell. Let us first briefly illus¬ 
trate implicit coercions in Coq. Assume a decidable indexed 
property on nat, which is used to define a type rich_nat: 

Variable P : nat —r Prop. 

Variable P-dec : V n nat, Decidable (P n). 

Def initionrich_nat := {HT nat | P r} 

To define an implicit coercion from values of type rich_nat 
to nat we first define a function with the appropriate type, 
and then declare it as an implicit Coercion: Definition 

rnat_to_nat : rich_nat — >■ nat := 
fun n => n.\. 

Coercion rnat_to_nat : rich-iiat >— » nat. 

We can now pass a rich_nat to a function that expects a nat, 
without having to explicitly apply the coercion function: 

Variable/ : nat — t nat 

Variable s : rich_nat. 

Check/ s. 


Implicit cast insertion. In order to implicitly insert casts, 
it is enough to define a standard implicit coercion based on 
a function that introduces casts. For instance, we define an 
implicit coercion (cast insertion) from nat to rich_nat: 

Def inition nat_to_rnat : nat — t rich_nat := ?. 
Coercion nat_to_mat : nat >—> rich-nat. 

Calling a function that expects a rich_nat with a nat 
argument is now type-correct. Under the hood, the implicit 
coercion takes care of inserting the cast: 

Variable g : rich_nat —r nat 
Variable n: nat 
Check g n. 

Compared to standard gradual typing, the limitation of 
this approach is that Coq does not support universal coer¬ 
cions, so one needs to explicitly define the specific coer¬ 
cions that are permitted. This is arguably less convenient 
than a general implicit cast insertion mechanism, but it is 
also more controlled. Because types are so central to Coq 
programming, it is unclear whether general implicit cast in¬ 
sertion would be useful and not an endless source of confu¬ 
sion. Actually, even in gradually-typed languages with much 
less powerful type systems, it has been argued that a mech¬ 
anism to control implicit cast insertion is important We 
believe that the implicit coercion mechanism of Coq com¬ 
bined with casts might be a good tradeoff in practice. 

6. Higher-Order Casts, Simply 

We now consider cast operators for functions. As expected, 
function casts are enforced lazily similarly to higher-order 
contracts d We first focus on non-dependent function 
types of the form A—iB. One could want to either strengthen 
the range of the function, claiming that the return type is { b : 
B | P b}, or vice-versa, to hide the fact that a function expects 
rich arguments of type {a : A \ Pa}. 

6.1 Strengthening the Range 

The cast_fun_range operator below takes a function of type 
A—>B and returns a function of type A / J b\. It 

simply casts the return value to the expected subset type: 

Def inition cast_fun_range (A B : Type) (P : B —>■ Prop) 
(i dec : V b. Decidable (P b)): 

(.4 ->£)->■ A ->■ {b:B\P 1} := 
fun/ a => ? (f a). 

Notation ”—>■?” := (cast_fun_range _ ). 

Example. We can cast a nat — >• nat function such as S 
(successor) to a function type that ensures the returned value 
is less than 10: 

Definition top_succ : nat — r {fcinat | n < 10} := —>•? S 
Then, as expected: 


10 https://coq. inria. fr/distrib/current/refman/Ref erence-Manual02ftY!?tbi ;Oin P u ^ e tOp_SUCC 6. 
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= (7; Le.le_n_S 7 9 ...) 

: {n : nat I n < 10} 

And: 

Eval compute in top_succ 9. 

= failed_cast 10 (11 <= 10) 

: {n : nat I n < 10} 

6.2 Weakening the Domain 

Similarly, cast_fun_dom turns a function of type {a : A 
P a} —»• B, which expects a value of a subset type, into a 
standard function of type A—kB, by casting the argument to 
the expected subset type: 

Definition cast_fun_dom (A B : Type) ( P : A —>■ Prop) 
(dec: V a. Decidable (P a)): 

{{a : A \ P a} —>■ B) —/ A B := 
fun / a =>•/ (? a). 

Notation ”?—>■” := (cast_fun_dom _ ). 

Example. The standard division function on natural num¬ 
bers in Coq, div, is total and pure, but incorrect: when the 
divisor is 0, the result is 0. We can use subset types to de¬ 
fine a pure and correct version, divide, which is total on a 
resUicted domain, by requiring its second argument to be 
sUictly positive: 

Definition divide: nat —r {n: nat | n > C} —> nat := 
fun a b => div a b.\. 

Using this function now forces the programmer to pro¬ 
vide a proof that the second argument is strictly positive. 
This can be achieved with the standard cast operator ?. Al¬ 
ternatively, we can cast divide into a function that accepts 
plain nat 3, but internally casts the second argument to en¬ 
sure it is strictly positive: 

Definition divide’: nat — / nat —/ nat := 
fun a =>■ ?—> (divide a). 

As expected, applying divide’ with 0 as second argument 
produces a cast failure. 

Eval compute in divide’ 1 0. 

= match (let (a, _) := failed_cast 0 (1 <= 0) 

: nat 

Arguably, it is more correct for division by zero to man¬ 
ifest as a failure than to silently returning 0. We will also 
see in Section [8] that weakening the domain of a function is 
helpful when extracting it to a target language that does not 
support subset types, because the assumptions expressed in 
the richly-typed world translate into runtime checks. 

7. Higher-Order Casts, Dependently 

The higher-order cast operators defined above are not ap¬ 
plicable when the target function type is dependently-typed. 
Recall that in Coq, a dependently-typed function has a type 


of the form V a: A, B a , meaning that the type of the result 
(. B a) can depend on the value of the argument a. 

For instance, in Section 12731 we cast compile to the de¬ 
pendent function type correct_comp, which is an alias for 
the type V e: exp, {p: prog | correct_prog e p\. An alternative 
would have been to downcast rune, which expects a correct 
compiler, to a looser function type that accepts any compiler 
(similarly to what we have done above with divide). We now 
discuss both forms of casts; as it turns out, weakening the 
domain of a dependently-typed function is a bit of a chal¬ 
lenge. 

7.1 Strengthening the Range 

Strengthening a function type so that it returns a rich de¬ 
pendent type is not more complex than with a simply-typed 
function; it just brings the possibility that the claimed prop¬ 
erty on the returned value also depends on the argument: 

Definition cast_forall_range (A: Type) ( B : A —> Type) 

( P : V a:A, B a —/ Prop) 

(i dec : V a (b : B a). Decidable ( P a b )): 

(7 a: A, B a) —r V a: A, {,b : B a \ P a b} := 
fun/ a =>• ? (f a). 

Notation ”V?” := (cast_forall_range _ ). 

Examples. We can cast a nat —»• nat function to a dependently- 
typed function that guarantees that it always returns a value 
that is greater than or equal to its argument: 

Definition f_inc : 

( nat — r nat ) —r V n : nat, nat | (n < »:)} := V?. 

Then, as expected: 

Eval compute in f_inc S 3. 

= (4; Le.le_n_S 23 ...) 

: {m : nat I 3 <= m} 

And: 

Eval compute in f_inc (fun _ =>■ O) 3. 

= failed_cast 0 (3 <= 0) 

: {m : nat I 3 <= m} 

The above example casts a simply-typed function to 
a dependently-typed function, also illustrating the binary 
property P a b in the range. In the following example, the 
casted function is dependently-typed. Consider the induc¬ 
tive type of length-indexed lists of nat and the dependently- 
typed constructor buikLlist: 

Inductive ilist : nat —r Set := 

| Nil : ilist O 

| Cons : V n, nat —t ilist n —* ilist (S n). 

Fixpoint buikLlist («: nat) : ilist n := 
match n with 
| O => Nil 

| S m => Cons _ O (build_list m ) 
end. 
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We can cast buildjist (of type V n nat, ilist ri) to a func¬ 
tion type that additionally guarantees that the produced list 
is not empty. 

Definition non_empty_build: 

V n : nat, { . : ilist n \ n > 0 } := V? buildjist. 

Then, as expected: 

Eval compute in non_empty_build 2. 

= (Cons 1 0 (Cons 0 0 Nil); ...) 

: {_ : ilist 2 I 2 > 0} 

And: 

Eval compute in non_empty_build 0. 

= failed_cast Nil (1 <= 0) 

: {_ : ilist 0 I 0 > 0} 

7.2 Weakening the Domain 

Consider a function that expects an argument of a subset type 
{a : A | P a}, and whose return type depends on the value 
component of the dependent pair. Such a function has type 
V x: {a : A \ P a}, B x.\. Weakening the domain in this case 
means casting this function to the dependent type V a : A, B 
a. 

Notably, defining such a cast operator leads to an interest¬ 
ing insight regarding casts in a dependently-typed language. 
Because cast hides a lie about a value, when casting the ar¬ 
gument of a dependently-typed function, the lie percolates at 
the type level due to the dependency. Consider the intuitive 
definition of cast_forall_dom, which simply applies cast to 
the argument: 

Definition cast_forall_dom (A: Type) (P: A — > Prop) 

( B : A — y Type) (dec: V a. Decidable (P a)): 

(V x: {a : A \ P a}, B x.\ ) —> (V a : A, B a) := 
fun/ a =>/ (? a). 

Coq (rightfully) complains that: 

The term "f (? a)" has type "B (? a).l" 
while it is expected to have type "B a". 

Indeed, the return type of the casted function can depend 
on the argument, yet we are lying about the argument by 
claiming that it has the subset type {a : A \ P a}. Therefore, 
in all honesty, the only thing we know about/ (? a) is that 
it has type B a only if the cast succeeds —in which case (? 
a).i = a. But the cast may fail, in which case la is not a 
dependent pair and (? a).\ cannot be reduced: it is a cast 
error at the type level. 

What can we do about this? We know that cast errors 
can occur, but we do not want to pollute all types with that 
uncertainty. Following the axiomatic approach to casts, we 
can introduce a second axiom, failed-cast-projl , to hide the 
fact that cast errors can occur at the type level. Note that 
we do not want to pose the equality (? a ).i = a as an axiom. 


otherwise we would be relying on the axiom even though the 
cast succeeds. The axiom is required only to pretend that the 
first projection of a failed cast is actually the casted valu JH: 

Axiom failed_cast_projl : 

V {A:Type} {P : A — * Prop} {o: A} (msg:P rop), 
(failed_cast (P:=P) a msg ). i = a. 

Using this axiom allows us to define an operator to hide casts 
from types, hide_cast_projl (notation [?]), as follows^ 

Definition hide_cast_projl (A: Type) (P: A —/ Prop) 

( B : A —>■ Type) (dec: V a. Decidable (P a)) (a:A): 

B (7 a). i —/ B a. 

Proof. 

unfold cast, case (dec a): intro p. 

- exact (fun h =>■ b ). 

- exact (fun b =4> eq_rect_ b _ 

(failed_cast_proj 1 (P a))). 

Defined. 

Notation ”[?]” := (hide_cast_projl _ ). 

The equality coming from failcd_cast_proj I is necessary to 
transform the term b of type B ( failed_cast _ P a msg).\ to 
a term of type B a. This is done using the elimination rule 
eq_rect of the equality type. Here again, we can see that a 
failed_cast_proj 1 error will only occur if the property P a 
does not hold. 

We can now define cast_forall_dom as expected, by 
adding the hiding of the cast in the return type: 

Definition cast_forall_dom (A: Type) (P: A —>■ Prop) 

(B: A —t Type) (dec: V a. Decidable (P a)): 
(7 x: {a : A \ P a} B x.i) —>■ (7 a : A, B a) := 
fun / a =► [?](/•(? a)). 

Notation ”?V” := (cast_forall_dom _ ). 

Example. Recall the length-indexed lists of Sect. 17. II Con¬ 
sider the following dependently-typed function with a rich 
domain type, which specifies that given a strictly positive 
nat , it returns an ilist of that length: 

Definition build_pos : 7 x: {,t : nat | n > 0 } ilist (x.i) := 
fun n => build_list (n. i). 

We can use ?7 to safely hide the requirement that n > 0: 
Definition build_pos’ : 7 n: nat, ilist n := ?7build_pos. 
Then, as expected: 

Eval compute in build_pos’ 2. 

= Cons 1 0 (Cons 0 0 Nil) 

: ilist 2 

11 The key word in the sentence is pretend : the new axiom does not allow 
one to actually project a value out of a failed cast; it only serves to hide the 
potential for cast failure from the types. 

12 This time, we use tactics to define hide_cast_projl, instead of giving the 
functional tenn explicitly as we did for cast. The reason is that because of 
the dependency, a simple pattern matching does not suffice and extra type 
annotations have to be added to match in order to help Coq typecheck the 
dependent pattern matching. 
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And we can now see failed_cast_proj 1 appearing: 

Eval compute in build_pos’ 0. 

= eq_rect . . . 

((fix build_list (n : nat) : ilist n := ...) 

(let (a, _) := failed_cast 0 (1 <= 0) in a)) 

0 (failed_cast_proj1 (1 <= 0)) 

: ilist 0 

8. Extraction 

An interesting feature of Coq in terms of bridging certified 
programming with practical developments is the possibility 
to extract definitions to mainstream languages. The standard 
distribution of Coq supports extraction to Ocaml, Haskell, 
and Scheme; and there exists several experimental projects 
for extracting Coq to other languages like Scala and Erlang. 

Coq establishes a strong distinction between programs 
(in Type), which have computational content, and proofs 
(in Prop), which are devoid of computational meaning and 
are therefore erased during extraction. This allows for ex¬ 
tracted programs to be efficient and not carry around the 
burden of unnecessary proof terms. However, this erasure 
of proofs also means that subset types are extracted to plain 
types, without any safeguards. It also means that the use of 
admitted properties is simply and unsafely erased! 

To address these issues, we can exploit our cast frame¬ 
work. By establishing a bridge between properties and com¬ 
putation, casts are extracted as runtime checks, and cast fail¬ 
ures manifest as runtime exceptions—which is exactly how 
standard casts work in mainstream programming languages. 
This ensures that the assumptions made by certified compo¬ 
nents extracted to a mainstream language are dynamically 
enforced. 

Example. Recall from Section 16.21 the divide function of 
type nat —> {n: nat | n > 0} —> nat To define divide, the 
programmer works under the assumption that the second 
argument is strictly positive. However, this guarantee is lost 
when extracting the function to a mainstream programming 
language, because the extracted function has the plain type 
nat->nat->nat: 

Definition divide: nat — r nat | n > C 1 } —>► nat := 

fun a b =>■ div a b.\. 

Extraction Language Ocaml. 

Extraction divide. 

let divide a b = div a b 

The dependent pair corresponding to the subset type has 
been erased, and divide does not check that the second argu¬ 
ment is positive (we extract nat to OCaml’s int): 

# divide 10;; 

- : int = 0 


If we instead first cast divide to the divide’ function with 
plain type nat -> nat -> nat, and then extract divide’: 

Definition divide’: nat —r nat —t nat := 
fun a => ?—> (divide a). 

Extraction divide’, 
let divide’ a = 

cast_fun_dom (decidable_le_nat 1) (divide a) 

The inserted cast translates to a runtime check in the 
extracted code, whose failure results in a runtime cast error: 

# divide’ 10;; 

Exception: Failure "Cast has failed". 

Extracting axioms as exceptions. By default, the use of an 
axiom translates to a runtime exception in Ocaml. In order 
to make the error message more informative, we explicitly 
instruct Coq to extract uses of failed-cast as follows! 13 ! 

Extract Constant failed-cast => 

’’failwith ’’’’Cast has failed”””. 

Appendix [B] which discusses evaluation regimes, in¬ 
cludes discussion about some subtleties that arise when ex¬ 
tracting to an eager language like Scheme or Ocaml. 

Finally, note that the second axiom we introduced in Sec¬ 
tion failed-cast-proj 1 , does not need to be extracted at 

all: it is used to convert two types that are equal after extrac¬ 
tion (because they only differ in propositional content). 

9. Properties 

The development of gradual checking of subset types we 
have presented is entirely internalized in Coq: we have 
neither extended the underlying theory nor modified the 
implementation. The only peculiarities are the use of the 
failed-cast and failed-cast-projl axioms. As a consequence, 
a number of properties come “for free”. 

Canonicity. Coq without axioms enjoys a canonicity prop¬ 
erty, which states that all normal forms correspond to canon¬ 
ical forms. For instance, all normal forms of type bool are 
either true or false. 

Cast errors. Canonicity is only violated by the use of ax¬ 
ioms. Here, this means that the only non-canonical normal 
forms are terms with failed-cast (or failed-cast-proj 1 ) in¬ 
side. More precisely, a cast failure in Coq is any term t such 
that t = E[f ailed_cast v p ], where v is the casted value 
and p is a false property (ditto for failed-cast-projl ). In Coq, 
for cast errors that manifest at the value level, the evaluation 
context E is determined by the evaluation regime specified 
when calling Eval. For cast errors that manifest at the type 

13 To be more helpful in the error reporting, we do provide a string represen- 
tation of the casted value by using a showable type class, similar to Show 
in Haskell (see code in the distribution). However, we cannot provide the 
information of the violated property, because there is currently no way to 
obtain the string representation of an arbitrary Prop within Coq. 
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level, E follows the reduction strategy for type conversion, 
which is coarsely a head normal-form evaluation with opti¬ 
mization for constants. 

Soundness via extraction. The canonicity of Coq and the 
definition of cast errors, together with the assumption that 
program extraction in Coq is correct (and axioms are ex¬ 
tracted as runtime errors), entail the typical type soundness 
property for gradually-typed programs, i.e. programs with 
safe runtime casts 1161 12611 : the only stuck terms at runtime 
are cast errors FI 

Termination of casts. Because decision procedures are de¬ 
fined within Coq, casts are guaranteed to terminate. This is 
in contras^ to some approaches, like hybrid type checking 
in Sage in which decision procedures are defined 

within a language for which termination is not guaranteed. 

Simplification at extraction. Because propositions are 
erased at extraction, the fit iled- cas t-proj I axiom is never 
extracted in the target language and thus cannot fail. This 
means that in the extracted program, hide_cast_projl is al¬ 
ways extracted to the identity function, and errors can only 
manifest through the failed-cast axiom. 

10. Casting More Dependent Types: Records 

Until now, we have developed the axiomatic approach to 
gradual verification in Coq with subset types, because they 
are the canonical way to attach a property to a value. How¬ 
ever, the approach is not specific to subset types and acco¬ 
modates other dependently-typed structures commonly used 
by Coq developers, such as record types. To stress that our 
approach is not restricted to subset types, we now illustrate 
how to deal with dependent records. We also use this exam¬ 
ple as a case study in customizing the synthesis of correct 
decision procedures through the Decidable type class. 

Rationals. Consider the prototypical example provided in 
the Coq reference manual l5 l: a record type for rational num¬ 
bers, which embeds the property that the divisor is not zero, 
and that the fraction is irreducible. The type of rational num¬ 
bers, with their properties, is defined as: 

Record Rat : Set := mkRat 
{sign : bool; 
top : nat, 
bottom : nat; 

Rat_bottom_cond : 0 f bottom; 

Rat_irred_cond : V x y z, 

y x x = top A z x x = bottom — 1 = x}. 

14 Note that if the target language is impure, then it is possible to break the 
safety of program extraction altogether (eg. by passing an impure Ocaml 
function as input to a Coq-extracted function). This general issue is inde¬ 
pendent of casting and beyond the scope of this work. Ensuring safe in¬ 
teroperability between a purely functional dependently-typed language like 
Coq and a language with impure features is a challenging research venue. 

15 https://coq.inria.fr/refman/Reference-Manual004.html#sec61 


Casting rationals. The property Rat_bottom_cond is obvi¬ 
ously decidable. It is less clear for the property Rat_irred_cond, 
which uses universal quantification. Indeed, in general, there 
is no decision procedure for a universally-quantified de¬ 
cidable property over natural numbers, because the set of 
natural numbers is infinite. So it seems we cannot use the 
cast framework to create rationals without having to provide 
proofs of their associated properties. 

Interestingly, it is possible to use casts for rationals de¬ 
spite the fact that Rat_irred_cond cannot be directly declared 
to be decidable. We review three different approaches in this 
section. They all exploit the fact that if we can prove that 
a decidable property is equivalent to Rat_irred_cond, then 
Rat_irred_cond is decidable CSectionO. 

We define a cast operator for Rat, which takes the three 
values for sign, top and bottom, two (implicitly-passed) de¬ 
cision procedures dec-rat-bottom and dec-rat-irred, and 
checks the two properties: 

Definition cast_Rat (s:bool) ( t b\ nat) 

{dec -rat-bottom : Decidable _} 

{dec-rat-irred : (0 k) —t Decidable _} : Rat := 
match dec _ with 
| ini Hb => 

match dec (Decidable := dec-rat-irred Hb) _ with 
| ini Hi =>■ mkRat s t b Hb Hi 
| _ =>■ failed-cast-Rat s t b 
end 

| _ =>■ failed-cast-Rat s t b 
end. 

As before, the definition of the cast operator appeals to an 
inconsistent axiom in the case a property is violated. The 
failed-cast-Rat axiom states that any three values are ade¬ 
quate to make up a Rat0 

Axiom failed-cast-Rat : V (s:bool) ( t b\ nat ). Rat. 

Note that we use a type dependency in cast_Rat to allow 
the decision procedure of dec-rat-irred to use the fact that 
Rat_bottom_cond holds in the branch where it is used. 

A decision procedure based on bounded quantification. 

A first approach to establish a decision procedure for irre- 
ducibility is to exploit that it is equivalent to the same prop¬ 
erty that quantifies over bounded natural numbers. We first 
define the type of bounded naturals (and we introduce an 
implicit coercion from bnat to nat): 

Definition bnat (n:nat) := {m : nat | m < r} 


16 It is necessary to define custom axioms and cast operators for each new 
record type. This limitation was not apparent with subset types, because 
they are a general purpose structure, while records are specific. To limit 
the burden of adoption, it would be interesting to define a Coq plugin that 
automatically generates the axioms and cast operators (whose definitions 
are quite straightforward). 
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and define a general instance of Decidable, which allows 
building a decision procedure for any universally-quantified 
property over bounded naturals: 

Instance Decidable_forall_bounded k 

(P:bnat A— ?-Prop) (HP : V n, Decidable ( P «)): 
Decidable (V n, P n). 

We can then establish how to synthesize a decision proce¬ 
dure for Rat_irred_cond by establishing that it is equivalent 
to a similar property, where the quantification is bounded by 
the max of top and bottom: 

Definition Rat_irred_cond_bounded top bottom ‘CO ^ 
bottom ): 

(7 x y z'. bnat (max top bottom), 

y x x = top A z x x = bottom — / 1 = x) 

(7 x y z'. nat y x x = top A z x x = bottom —t 1 = x) 

Note that it is crucial to be able to use the fact that 0 ^ 
bottom holds in the proof of equivalence, as it simply does 
not hold when bottom = 0. 

Then, the Decidable instance for Rat_irred_cond is sim¬ 
ply defined by connecting it to the bounded property through 
the Decidable_equivalent instance: 

Instance Rat_irred_cond_dec_bounded top bottom 
‘(0 ^ bottom) : Decidable _ := 
Decidable_equivalent 

(Rat_irred_cond_bounded top bottom H). 

Example. It is now possible to define a rational number 
without having to prove the two side conditions. 

Definition Rat_good := cast_Rat true 5 6. 

Eval compute in top Rat_good. 

= 5 
: nat 

Exactly in the same way as the first projection of a dependent 
pair cannot be recovered if the cast fails, sign, top or bottom 
can not be recovered if cast_Rat fails. 

Definition Rat_bad := cast_Rat true 5 10. 

Eval compute in top Rat_bad. 

= let (_, top, bottom, _, _) := 

failed_cast_Rat true 5 10 in top 

: nat 

Note that the evaluation of top Rat_bad takes a significant 
amount of time, because the decision procedure involves 
checking every possible x y z: bnat 10, which amounts to 
checking more than 1000 properties. Indeed, a simple cast 
as above takes around 2 seconds on a recent computer. 

We now show that we can improve the cast on rational 
numbers by using more efficient decision procedures over 
equivalent properties. 


A decision procedure using binary natural numbers. In 
the Coq standard library, there is a binary representation of 
integers, Z, which is much more efficient but less easy to 
reason about. We can exploit this representation by showing 
that the property Rat_irred_cond in Z implies the property 
in nat: 

Definition Rat_irred_cond_Z top bottom ‘(0 ^ bottom ): 
(7 x y z. bnat (max top bottom), 

Z.mul y x = top A Z.mul z x = bottom —/ I = .r) 

(7 x y z: nat, y x x = top A z x x = bottom — / 1 = x) 
Instance Rat_irred_cond_dec top bottom ‘(0 ^ bottom ): 
Decidable _ := 

Decidable_equivalent 

(Rat_irred_cond_Z top bottom H). 

In this manner, the time for evaluating the same “bad” 
rational number cast as Rat_bad decreases by a factor of 10! 

A decision procedure based on gcd. We can go even one 
step further and avoid doing an exhaustive (even if finite) 
check: the property Rat_irred_cond is actually equivalent to 
the gcd of top and bottom being equal to 1: 

Definition Rat_irred_cond_gcd top bottom ‘(0 ^ bot¬ 
tom) : 

(Z.gcd (top: nat) bottom = 1) 

(7 xy z,y x x = top A z x x = bottom —/ 1 = .v) 

Instance Rat_irred_cond_gcd_dec top bottom 
( Hbot : 0 ^ bottom) : Decidable _ := 
Decidable_equivalent 

(Rat_irred_cond_gcd top bottom Hbot). 

Computing the same bad cast is now instantaneous. 


11. Related Work 

There is plenty of work on rich types like refinement types [ 4 ], 
11, 20,131] (which roughly correspond to the subset types of 
Coq j 27|| ). focusing mostly on how to maintain statically 
decidable checking (eg. through SMT solvers) while of¬ 
fering a refinement logic as expressive as possible. Liquid 
types [20], and their subsequent improvements [6, 29], are 
one of the most salient example of this line of work. Of 
course, to remain statically decidable, the refinement logics 
are necessarily less expressive than higher-order logics such 
as Coq and Agda. In this work we focus on Coq, giving up 
fully automatic verification. This being said, Coq allows a 
mix of automatic and manual theorem proving, and we ex¬ 
tend this combination with the possibility to lift proofs of 
decidable properties to delayed checks with casts. Notably, 
the set (and shape) of decidable properties is not hardwired 
in the language, but is derived from an extensible library. We 
believe our approach is applicable to Agda as well, since the 
main elements (axioms and type classes) are also supported 
in Agda. However, the devil is certainly in the details. 

Interestingly, Seidel et al. recently developed an approach 
called type targeted testing to exploit refinement type anno- 
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tations not for static checking, but for randomized property- 
based testing l23ll . This supports a progressive approach 
by which programmers can first enjoy some benefits of 
(unchecked) refinement type annotations for testing, and 
then eventually turn to full static checking when they de¬ 
sire. While the authors informally qualify the methodology 
as “gradual”, it is quite different from other gradual checking 
work, which focuses on mixing static and dynamic check¬ 
ing (26]. Gradual typing has been extended to a whole range 
of rich type disciplines: typestates [12, 30l l, information flow 
typing and security types @], ownership types (24], an¬ 
notated type systems 1281. and effects jjt], but not to a full¬ 
blown dependently-typed language. 

This work is directly related to the work of Ou et al. on 
combining dependent types and simple types Hsil , as well 
as the work on hybrid type checking 1171], as supported in 
Sage H]. Ou et al. develop a core language with depen¬ 
dent function types and subset types augmented with three 
special commands: simple{e}, to denote that expression e 
is simply well-typed, dependent {c:}, to denote that the type 
checker should statically check all dependent constraints in 
e, and assert(e,r) to check at runtime that e produces a 
value of (possibly-dependent) type r. The semantics of the 
source language is given by translation to an internal lan¬ 
guage, which uses a type coercion judgment that inserts run¬ 
time checks when needed. In hybrid type checking, the lan¬ 
guage includes arbitrary refinements on base types, and the 
type system tries to statically decide implications between 
predicates using an external theorem prover. If it is not stati¬ 
cally possible to either verify or refute an implication, a cast 
is inserted to defer checking to runtime. 

In both approaches, refinements are directly expressed in 
the base language, as boolean expressions; therefore it suf¬ 
fices to evaluate the refinement expression itself at runtime 
to dynamically determine whether the refinement holds. (In 
hybrid type checking, refinements are not guaranteed to ter¬ 
minate, while in Ou et al., refinements are drawn from a pure 
subset of expressions.) In both cases, arbitrary logical prop¬ 
erties cannot be expressed: the refinements directly corre¬ 
spond to boolean decision procedures, without the possibil¬ 
ity to specify their logical meaning (see also AppendixlAlfor 
a discussion of boolean reflection). In particular, there are no 
ways for programmers to give proof terms explicitly, which 
means that it is impossible to marry non-decidable (explic¬ 
itly proven) properties with decidable ones (which may vol¬ 
untarily be proven or deferred). 


12. Conclusion 

We exposed an approach to support gradual certified pro¬ 
gramming in Coq. When initially engaging in this project, 
we anticipated a painful extension to the theory and imple¬ 
mentation of Coq. Much to our surprise, it was possible to 
achieve our objectives in a simple and elegant (albeit slightly 
heretical) manner, exploiting axioms and type classes. The 


cast framework is barely over 50 lines of Coq, to which we 
have to add the expansion of the Coq/HoTT Decidable li¬ 
brary, which is useful beyond this work, and could be re¬ 
placed by a different decidability framework. A limitation of 
the internalized approach is that it does not support blame 
assignment J3, because it would be necessary to modify 
reduction to track blame labels transparently. 

An interesting track to explore is to make the axiomatic 
approach to casts less heretical, by requiring the claimed 
property to be inhabited (this would rule out direct claims of 
False, for instance). The counterpart is that it requires some 
additional effort from the programmer—it may be possible 
to automatically find witnesses in certain cases. Also, the 
monadic version seems perfectly reasonable if extraction is 
the main objective, because upon extraction we can elimi¬ 
nate the success case of the error monad, and turn the failure 
case into a runtime exception. Additionally, the decidability 
constraint could be relaxed by only requiring a sound ap¬ 
proximation of the property to be decidable, not necessarily 
the property itself. Finally, we can optimize the cast proce¬ 
dure so that it does not execute the decision procedure if the 
property has been statically proven. 
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A. A Note on Boolean Reflection 


Eval compute in g (? 0). 


An alternative approach for the definition of decision proce¬ 
dures is to use boolean reflection , i.e. considering that the 
decision procedure is the property. 


Instance Decidable_bool ( b : bool) : 

Decidable (if b then True else False). 

However, while using boolean reflection can be conve¬ 
nient, there is no “safeguard” that the procedure is correctly 
implemented: the implementation is the specification. An¬ 
other limitation is that the information reported to the pro¬ 
grammer is unhelpful: if the cast succeeds, the proof term 
is /; if the cast fails, the failed property is False While the 
proof term is arguably irrelevant, the information about the 
failed property can be very helpful for debugging. 

Both issues can nevertheless been solved by having both 
the boolean and the property, and formally establishing the 
relation between both, similarly to what is done in the Ss- 
re fleet 0 library or the reflect inductive in Coq. This 
boolean/proposition relation mechanism is also provided in 
the DecidableClass library of Coq. To avoid name conflicts 
(the class is also named Decidable), we provide the same 
class under the name Decidable_relate: 


Class Decidable_relate (P : Prop) := { 
Decidable_witness: bool; 

Decidable_spec: Decidable_witness = true P 

}■ 


Actually the two presentations of decidability are equivalent. 
Indeed, the same development has been done in Ssreflecf^l 
using canonical structures [21] instead of type classes to au¬ 
tomatically infer complex decision procedures from simpler 
ones 0.' This shows that the decidability mechanism is or¬ 
thogonal to the cast operators we propose.^ 


B. A Note on Evaluation Regimes 

Recall that Coq does not impose any fixed reduction strat¬ 
egy. Instead, Eval is parameterized by a reduction strat¬ 
egy, called a conversion tactic, such as cbv (aka. compute), 
lazy, hnf, simpl, etc. 

In addition to understanding the impact of reduction 
strategies on the results of computations with casts, it is 
crucial to understand the impact of representing cast fail¬ 
ures through an axiom. Consider a function g that expects a 
{n:nat | n > 0}, but actually never uses its argument: 

Definitiong ( x: {,i: nat | n > C}) := 1. 

Typically, one would expect that evaluating g (? 0) with a 
lazy reduction would produce 1, while using an eager strat¬ 
egy like compute would reveal the failed cast. However: 

17 The Ssreflect implementation was done by Ilya Sergey. 

18 The Decidable library is currently much less furnished than the Ssreflect 
library using boolean reflection, but its extension with instances similar to 
the ones implemented in Ssreflect is straightforward. 


= 1 
: nat 

The reason is that a cast error in Coq is not an error per 
se (Coq has no such mechanism): it is just a non-canonical 
normal form. Therefore, even with an eager strategy, g (? 0) 
simply returns 1. The cast is eagerly evaluated, and fails; but 
this only means that g is called with f ailed_cast as a fully- 
evaluated argument. Because g does not touch its argument, 
the cast failure goes unnoticed. 

On the contrary, if we extract the code to Ocaml (recall 
Section [8]), the cast violation is reported immediately as an 
exception: 

Definition client ( x : nat) := g (? x ). 

Extraction Language Ocaml. 

Extraction ’’test.ml” client. 

# client 1;; 

- : int = 1 

# client 0;; 

Exception: Failure "Cast has failed". 

While, as expected, the error goes unnoticed in Haskell, 
because of its lazy evaluation regime. 

Extraction Language Haskell. 

Extraction ’’test.hs” client. 

*Test> client 1 
1 

*Test> client 0 
1 

Extraction of axioms in eager languages. There is one 
last detail to discuss when considering extraction to eager 
languages. As defined, failed-cast and cast are extracted as 
follows in Ocaml: 

let failed_cast = 

failwith "Cast has failed" 

let cast dec a = 
match dec a with 
I Ini -> a 
I Inr _ -> failed_cast 

While these definitions are perfectly fine for a lazy lan¬ 
guage like Haskell, in an eager language like Ocaml or 
Scheme they imply that loading the definition of f ailed_cast 
fails directly. The solution is to enforce the inlining of 
failed-cast: 

Extraction Inline failed_cast. 

As a result, failed_cast is not extracted as a separate 
definition, and cast uses the Ocaml failwith function di¬ 
rectly. 
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